<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Generic Problems View</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body>
<h1>Generic Problems View</h1>
<p>The purpose of this document is to present details of the solutions for the 
  generic Problems view presented in <a href="logical-support.html">Enabling Logical 
  Model Integration in the Eclipse Platform</a>.</p>
<h2>Generic Views In the Eclipse Platform</h2>
<p>There are several views in the Eclipse platform that have generic titles but 
  only displays the elements associated with the Platform Resource model. For 
  instance, the Problems view can only display prblems that are associated with 
  file system resources. This forces other models to either associate their problems 
  with file system resources or create their own view. There are several such 
  views in the Eclipe Platform:</p>
<ul>
  <li><strong>Problems view</strong>: Displays the list of problems that exist 
    in the workspace. Provides links to the resource where the problem exists 
    and possible to one or more solutons (through QuickFixes).</li>
  <li><strong>Bookmark view</strong>: Similar nature to the problems view.</li>
  <li><strong>Tasks view</strong>: Displays a list of tasks the user should or 
    could perform.Currently, tasks are tied to resources just like problems and 
    bookmarks so a similar solution could be applied to the Tasks view. However, 
    one could easily argue that tasks could be associated with multiple resources 
    (or no resources). This makes generalizing Task related concepts more difficult 
    than that of problems and bookmarks.</li>
  <li><strong>Resource Navigator view</strong>: Displays the elements that exist 
    in the workspace in a form that allows the user to navigate the workspace. 
    There is work in the WTP project on a generic navigator and the rumor is that 
    this may get pushed down to the Platform sometime after 3.1.</li>
</ul>
<p>The Search view already has support for searches from different model domains. 
  This comes in two forms:</p>
<ul>
  <li>The Platform has pluggable support for search types. Some example search 
    types are File Search, Java Search, Plugin Search and NLS Search. Each search 
    type, when executed, adds a custom search result page to the search view.</li>
  <li>Some search types support participation. For instance the Java Search allows 
    particpants to be added to Java searches.</li>
</ul>
<p>The main issue in generalizing these views is determining the best way to combine 
  the problems, tasks or elements from multiple models in the same view. There 
  are two obvious ways to do this:</p>
<ul>
  <li>show the problems, tasks or elements from all models in the same view. 
    <ul>
      <li>This is the approach taken in the generic navigator proposal</li>
      <li>Need grouping or filtering APIs to provide scalability</li>
    </ul>
  </li>
  <li>provide a paged view where each page shows the problems, tasks or elements 
    from a particular model
    <ul>
      <li>This is the approach taken by the Search view</li>
      <li>Still needs grouping or filtering to deal with scalability</li>
    </ul>
  </li>
</ul>
<p>Each of these has their advantages and disadvantages. A single view frees the 
  user from selecting which model to look at but such a view does not scale well. 
  A paged view provides a means of top level filtering by model (advantage or 
  disadvantage?) but can still have scalability issues. The nature of each particular 
  view will dictate which approach is more suitable. This document focuses on 
  the Problems view as it was identified in the scenarios presented in <a href="logical-support.html">Enabling 
  Logical Model Integration in the Eclipse Platform</a>.</p>
<h2>The Problems View</h2>
<p>This view seems to be of most interest to modeling tools built on top of the 
  Platform since it deals with helping the user correct model inconsistencies. 
  For this reason, we will outline the beginnings of a possible solution here. 
</p>
<p>Based on several discussions on this topic, the following is a list of the 
  desired properties of a generic Problems view.</p>
<ul>
  <li>All the problems appear in a single view (i.e. not multiple pages) but are 
    not tied to resource markers 
    <ul>
      <li>Requires a generic problem API</li>
    </ul>
  </li>
  <li>Support filtering 
    <ul>
      <li>include/exclude problems from different domains</li>
      <li>by severity</li>
      <li>domain specific</li>
      <li>selection</li>
    </ul>
  </li>
  <li>Support grouping 
    <ul>
      <li> arrange problems hierarchically. e.g. problems grouped by logical or 
        physical resource</li>
    </ul>
  </li>
  <li>Sorting 
    <ul>
      <li>sorting across domains 
        <ul>
          <li>severity</li>
          <li>description</li>
        </ul>
      </li>
      <li>domain specific</li>
    </ul>
  </li>
  <li>Actions 
    <ul>
      <li>Goto action, Show in and QuickFix support that performs an action appropriate 
        for the selected problem</li>
    </ul>
  </li>
  <li>Efficient addition and removal of problems 
    <ul>
      <li>problems may be removed/added one at a time or a domain at a time</li>
    </ul>
  </li>
  <li>Display information appropriate for problem type 
    <ul>
      <li>generic columns (severity, description, resource, path, location in 
        resource)</li>
      <li>allow user configuration of displayed columns (included domain specific 
        columns)</li>
      <li>support separate pane that shows details of selected problem or alternate 
        views of the problem (i.e. problem dependency graph)</li>
    </ul>
  </li>
</ul>
<p>&nbsp;</p>
<h2>Status</h2>
<p>Here is the status of this work as of 3.1 M5</p>
<p>Generic Views: This needs to be driven by model owners with help from Platform 
  committers. Until model teams step forward and dedicate resources to this problem, 
  it is unlikely that work will progress.</p>
<p>&nbsp;</p>
</body>
</html>
